In many multiprocessor environments, inter-processor communication is provided through shared global memory. Access to this memory is generally protected through locks. The latency for access to these resources is coupled through the critical section of code and includes acquiring the lock, reading the data, writing the data, and finally releasing the lock. Note, nothing described or referenced in this document is admitted as prior art to this application unless explicitly so stated.
One such prior approach is illustrated in FIG. 1, which shows how three requesters request and gain access to protected data. Note, as shown in FIG. 1, the lock manager is independent of the storage mechanism as it does not access the lock protected data from its native storage. In fact, the lock manager of FIG. 1 never communicates nor otherwise processes a value of the protected data.
As shown, each requester sends a request to the lock manager, which provides independent access to the protected data by sending a grant message to one of the requesters. The granted requester then reads the protected data, performs its processing, writes the protected data back to memory, and then sends a release request to the lock manager to indicate that it is done with the protected data. This process repeats and a next requester is granted access to the data. Thus, there can be significant amount of latency that is exposed in the critical section of code, especially when multiple processors are queued up behind a single locking queue. The significant amount of latency is also true of processors that rely on caching within the processor units to provide temporary storage as well as provide direct inter-processor communication to transfer data.
Also, one known system includes a lock manager in an I/O subsystem which allows a message to include both locking and data storage requests. This allows a requester proxy process in the I/O subsystem to receive a message with both a lock request and an I/O request. In response, this proxy process makes a request to the lock manager for the lock, and in response to a grant, it then makes the corresponding I/O request corresponding to the I/O request and its native storage. This approach may reduce some messages and latency when the protected data is located in another subsystem, but in response to each grant, the I/O native storage is still accessed.